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The field of Avionics is advancing far more rapidly in terrestrial applications than in spaceflight applications. 
Spaceflight Avionics are not keeping pace with expectations set by terrestrial experience, nor are they keeping pace 
with the need for increasingly complex automation and crew interfaces as we move beyond Low Earth Orbit. NASA 
must take advantage of the strides being made by both space-related and terrestrial industries to drive our 
development and sustaining costs down. This paper describes ongoing efforts by the Avionics Architectures for 
Exploration (AAE) project chartered by NASA’s Advanced Exploration Systems (AES) Program to evaluate new 
avionic architectures and technologies, provide objective comparisons of them, and mature selected technologies for 
flight and for use by other AES projects. This paper discusses the AAE project’s FY14 goals, current achievements, 
and future plans. 


I. Introduction 

The field of Avionics is advancing far more rapidly in terrestrial applications than in spaceflight applications. 
Spaceflight Avionics are not keeping pace with expectations set by terrestrial experience, nor are they keeping pace 
with the need for increasingly complex automation and crew interfaces as we move beyond Low Earth Orbit. NASA 
must take advantage of the strides being made by both space-related and terrestrial industries to drive our 
development and sustaining costs down. This paper describes ongoing efforts by the Avionics Architectures for 
Exploration (AAE) project chartered by NASA’s Advanced Exploration Systems (AES) Program to evaluate new 
avionic architectures and technologies, provide objective comparisons of them, and mature selected technologies for 
flight and for use by other AES projects. The AAE project team includes members from most NASA centers, and 
from industry. 

It is our intent to develop a common core avionic system that has standard capabilities and interfaces, and 
contains the basic elements and functionality needed for any spacecraft. This common core will be scalable and 
tailored to specific missions. It will incorporate hardware and software from multiple vendors, and be upgradeable in 
order to infuse incremental capabilities and new technologies. It will maximize the use of reconfigurable open 
source software (e.g., Goddard Space Flight Center’s (GSFC’s) Core Flight Software (CFS)). 

Our long-term focus is on improving functionality, reliability, and autonomy, while reducing size, weight, and 
power. Where possible, we will leverage terrestrial commercial capabilities to drive down development and 
sustaining costs. We will select promising technologies for evaluation, compare them in an objective manner, and 
mature them to be available for future programs. 

The remainder of this paper describes our approach, technical areas of emphasis, integrated test experience and 
results as of mid-2014, and future plans. As a part of the AES Program, we are encouraged to set aggressive goals 
and fall short if necessary, rather than to set our sights too low. We are also asked to emphasize providing our 
personnel with hands-on experience in development, integration, and testing. That we have embraced both of these 
philosophies will be evident in the descriptions below. 


II. Approach 

Our overall approach emphasizes the need for testing of different alternatives to provide objective evaluations of 
the relative merits of architectures and technologies. Technologies selected for evaluation include both “legacy” 
systems (e.g., MIL-STD-1553B), and those included in technology roadmaps produced by NASA’s Office of Chief 
Technologist (OCT), Avionics Steering Committee (ASC), and Space Communications and Navigation (SCaN) 
Office. We recognize that any future exploration vehicles will likely be composed of a cluster of more specialized 
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vehicles deployed at different times by various organizations/contractors (perhaps from different countries), and that 
we must address how these specialized vehicles interact during all mission phases. Although we are focused on 
avionics for Human Spaceflight, we are considering technologies applicable for both crewed and robotic vehicles. 

Operations on both the Space Shuttle and International Space Station (ISS) have shown the importance of an 
Ethernet LAN on a vehicle for crew use, both to ship large volumes of data (including imagery) and to enable the 
use of terrestrially available Commercial Off-The-Shelf (COTS) products (hardware and software). Both of these 
vehicles were initially designed without an Ethernet Local Area Network (LAN) which was then added at significant 
cost. The Space Shuttle was designed before the wide availability of LAN technology of any kind. The ISS was 
designed with a Payload Ethernet Hub Gateway (PEHG), but this capability was limited to routing payload data, 
principally for downlink via the Ku-Band system; it did not provide anything like a LAN for the crew to use. 

Based on our experience, Ethernet will be needed for any future crewed mission, and we want to leverage it for 
both COTS products and our terrestrial experience base. Hence, we decided to treat Ethernet as a fundamental part 
of the onboard architecture, and then evaluate what capabilities need to be added for command and control 
functions. Our initial areas of investigation center on the use of time-triggered and non-deterministic Ethernet for all 
vehicle functions. We are also looking at ways to interface an Ethernet backbone with other control bus protocols 
(1553B, SpaceWire, etc.). 

In addition, we are emphasizing the investigation of human interfaces; more powerful processors and network 
configurations; wireless technologies for both networking and instrumentation; and flexible long-haul 
communications technology. 

A. High-Level Challenges and Guidelines 

As part of our initial efforts, we identified a set of high level challenges: 

• Future exploration vehicles are undefined, but are likely to be an aggregate of multiple vehicles from 
multiple sources. This will drive sparing, redundancy, etc. 

• Size, Weight, and Power (SWAP) must always be minimized 

• Processing requirements exceed that which can be provided by existing Space Hardened Avionics (e.g.. 
Power PC-based Rad750) 

• The Radiation Environment at HEO and beyond is much worse than it is at LEO (the environment with 
which HSF has the most operational experience). 

• Because of the radiation environment, we cannot rely on COTS hardware for additional processing 
capabilities as we have done on Shuttle and ISS (i.e., laptops aren’t likely to work reliably) 

• Exploration vehicle requirements will change/grow over the vehicle’s lifetime, as will the expectations set 
by Terrestrial State-of-the-Art. We need to accommodate these changes without undue expense. 

These high level challenges, along with other project level decisions, lead to the following set of architectural 
guidelines: 

• Minimize Avionics SWAP in the Flight Vehicle. Use wireless LANs and sensor networks where possible. 
Use low/no power sensors (“Zero Wire”) whenever practical. Minimize total wiring on the vehicle (using 
topologies, VPNs, etc.). Minimize unique components for sparing. 

• Keep the architecture and design modular so we can launch incrementally. Allow capabilities to be 
integrated into the vehicle when they are needed, or earlier if it makes sense from an available launch mass 
perspective. 

• Minimize Cost. Use existing capabilities to avoid near-term DDT&E. Allow for growth using new 
technology to avoid future DDT&E. Allow for infusion of new technology to reduce sustaining effort. 
Look for places where improved Avionics can drive down overall vehicle costs. 

• Minimize Risk. Use proven technology for critical functions. Use existing capabilities to minimize 
schedule risk. 

• Minimize logistics and maintenance. Pay particular attention to the trade-off between utilizing precious 
habitable volume for mounting avionics inside the spacecraft versus the effort required for external 
maintenance via EVA. 

• Support Heterogeneity. We cannot expect every module of an aggregate vehicle to be the same. No one 
architecture/design will be an acceptable answer for everything. 

• Strive for “Commonality”. This cannot mean picking a set of components/boards/boxes to be used in 
multiple vehicles developed over long periods of time by different vendors, but it could mean picking the 
same components/boards/boxes to be used throughout a vehicle. It must mean developing a way for these 



different things to talk to each other. It should mean making sure that things of a similar type can be 
exchanged, to allow for minimal sparing. 

• Provide Ethernet on the vehicle for crew support. 

• Maximize the use of Core Flight Software (CFS). Another AES-funded effort at JSC is the Core Flight 
Software (CFS) project. Briefly stated, the Core Flight Software Project’s objective is to evolve and extend 
the reusability of GSFC’s Core Flight Software System into human-rated systems, thus enabling low cost, 
and rapid access to space. It was decided that the AAE project would make maximum use of CFS. This 
approach should maximize our ability to leverage platforms, resources and skills from synergetic 
programs/projects for development of next generation human-rated space software systems and utilize 
these products in direct support of development and certification of future manned programs. 

• Use IPAS and F.F. In order to maximize our return on investment, the AAE project has made extensive 
use of the Flight Deck of the Future (F.F) and the Integrated Power, Avionics, and Software (IPAS) 
capability developed by JSC Engineering. IPAS is multi-system environment where next generation flight 
systems can be tested and demonstrated. It provides multi-mission/multi-vehicle simulations, a common set 
of test services, access to a variety of actual sensors and effectors, and access via the Distributed Simulation 
Network (DSNet) to capabilities at multiple NASA centers 1 . The F.F focuses primarily on the human- 
machine interface. It allows us to evaluate different interface technologies together with personnel from 
Flight Crew Operations, Human Health and Performance, and other stakeholders. 

B. Standards and Specifications 

We established a lean set of interface standards & specifications for our use in FY13, with the expectation that 
they would be refined and extended as needed for our future efforts. 

Table 1. Interface Standards and Specifications 


Interface Type 

Standard/Specification 

1553 

MIL-STD-1553B 

Space Wire 

ECSS E-ST-50-12C 

Low Speed Serial 

EIA Standard RS-232-C 

High Speed Serial 

EIA Standard RS-422 

Ethernet 

IEEE 802.3™ -2005 

Time Triggered Ethernet (TTE) 

SAE AS6802-2011 

Wireless LAN 

IEEE 802.11™ -2005 

Wireless Sensors 

ISA 100.1 la-2012 


C. Requirements 

Generic, high-level avionic system requirements were developed to aid in the objective evaluation of different 
architectures. Like the standards & specifications, these were established with the expectation that they would be 
refined and extended as needed for our future efforts. These requirements were not formally derived, but were 
established through a process of brainstorming, comparison with mission requirements sets being developed by 
NASA in the same timeframe, and vetting during Technical Interchange Meetings. These requirements are listed 
below. 

Spacecraft Vehicle Avionics. . . 

• Shall be capable of functioning in deep space (e.g., beyond LEO) 

• Shall be capable of supporting crewed missions 

• When uncrewed, shall be capable of autonomous operations for TBD duration 

• When uncrewed, shall be capable of being remotely operated from Earth, or elsewhere 

• Shall provide capabilities to support science, technology, and research payloads 

• Shall support visiting vehicles, both crewed and robotic 

• Shall support logistics resupply 

• Shall support expansion of vehicle capabilities 

• Shall support TBD EVR/EVA proximity operations 

• Shall support planetary/surface human/robotic operations 




III. FY14 Plan and Status 

During FY13, the AAE Project was able to successfully demonstrate a plausible avionics architecture for a 
notional L2 Station. We were also able to make significant strides toward our goal of a flexible avionics architecture 
that can be used to evaluate future concepts/architectures/components for both our nominal L2 Station and other 
vehicles 1 . 

Our architecture must use open interface standards and reconfigurable open source software. It will also have to 
contain the basic core elements and functionality required for any spacecraft as well as be scalable and tailor-able to 
different missions. It must allow integration of hardware from multiple vendors and international partners. It will 
also provide us the ability to evaluate and use evolving (near launch) technology. This ability of our robust 
architecture means that we will be able to continuously upgrade our capabilities and infuse new technologies with 
cost effective validation. 

During FY14, our efforts have been centered on incremental architectural upgrades applied to different mission 
scenarios. These upgrades and scenarios are evaluated during periodic Integrated Tests (IT’s). We have so far 
conducted two IT’s (IT#4 in January, and IT#5 in May), with a third (IT#6) planned during September 2014. The 
following sub-sections describe the goals and accomplishments for each of our technical Areas of Emphasis 
(AOEs), along with our current plans for the remainder of FY14. Our plans and strategies for subsequent FYs are 
described in Section IV. 


A. Processors, Networks, and Instrumentation (PNI) 

One goal of PNI is to continue the successful loading of Core Flight Executive (CFE) on as many “path-to- 
flight” processors as possible. We have successfully loaded Core Flight Software on multiple single board 
computers with different operating systems as shown in Table [III. A. 1 ] . By the end of FY14, we hope to 
demonstrate the use of CFS on a Maxwell SCS-750 using RTEMS operating system; however, this is in doubt due 
to resource limitations. 


Table III. A. 1 . Processors and Operating Systems supported by AAE 


Vendor 

Type 

Model # 

CPU 

MIPS 

Operating 

System 

Path-to-Flight 

Qty 

Honeywell 

CPU 

B787 

FCM 


Integrity 

Yes 

4 

Ai Tech 

CPU 

S950 

PPC750FX 

1600-2300 

VxWorks 

Yes 

4 

Ai Tech 

Network 

S750 




Yes 

4 

Space Micro 

CPU 

Proton 400 

PPC e500 
2 Cores 

5700 

@1.2 Ghz 

VxWorks/ 

Linux 

Yes 

2 

Maxwell 

CPU 

SCS750 

PPC750FX 

1800 

VxWorks 

RTEMS 

Yes 

2 

Raspberry 

CPU 

PI 

ARM 7 


Linux 

Unknown 

>5 

TILERA 

CPU 

Gx36 

TILE-Gx8036 

TBD 

1.0- 1.2 GHZ 

TBD 

TBD 

1-CFS 

Leon 4 

CPU 

SPARC-V8 

LEON4 

TBD 

TBD 

YES 

1-CFS 


For the Primary Flight Computer in our architecture, we have developed a method of Hot Backup. This was 
demonstrated by our ability to successfully run two dissimilar machines running dissimilar operating systems over 


an Ethernet network during FY13. During IT#5 we were able to extend this Hot Backup with non- flight processors 
using Time Triggered Ethernet (TTE) as shown in figure [III.A.l]. By the end of FY14, it is our intent to 
demonstrate this same capability using a path-to-flight Proton processor using Linux, and to integrate it with other 
flight systems as shown in figure [III.A.2]. We will also provide a standalone CFS quad voting software 
demonstration during IT#6. This demonstration will use at least three unique combinations of processor and 
operating system. In the future we will be merging these capabilities with our integrated AAE architecture. 



Figure III.A.l. Standalone Hot Backup with non-flight processors using Time Triggered Ethernet (TTE) 



Figure III.A.2. Hot Backup with flight processors using Time Triggered Ethernet (TTE) 


In addition, we have begun the layout of additional network interface boards for inclusion in our Common 
Avionics Enabler (CAE) Hardware. Glenn Research Center had designed a Space Wire Interface Card and the code 
for this board is being developed by Langley Research Center. In addition, Langley is also writing the code for MIL- 
STD -1553B Interface Card designed by Johnson Space Center. These capabilities are targeted for demonstration by 
the end of FY14. 







B. 


Communications / DTN 


With the recent advances in microelectronics, wireless transceivers are becoming more versatile, powerful, and 
portable. This has enabled software-defined radio (SDR) technology, where the radio transceivers perform the 
baseband processing functions entirely digitally, including modulation/demodulation, error correction coding, and 
compression/decompression. 

To achieve the maximum benefit, an SDR must not only be reconfigurable, but it must also have the ability to 
observe and measure the state of the operating environment and then intelligently learn and adapt as required. The 
AAE project is developing these capabilities, which are the fundamentals of cognitive radio (CR) communications. 

SDR and CR technologies will be of great benefit to NASA as they allow for increased interoperability due to 
radio flexibility, interference mitigation by detecting and avoiding potential interferes, higher data throughput by 
using scarce spectrum efficiently, and lower upgrade costs as the radios are able to adapt to different user/mission 
needs rather than going through expensive hardware replacement. 



< > • Direct to Earth Links 

• IOAG Service catalog for the mission phase (SN, NEN, DSN) - QPSK / BPSK 

< > • Proximity (vehicle to vehicle) and Surface Communications 

• Wireless Local Area Network with Meshing -- 802.11 Variant 

• Potential Lunar Relay using Cubesat/Microsat 

Figure III.B.l. AAE Baseline Communication Architecture for Human Exploration 


Disruption Tolerant Networking (DTN) protocol is a fundamental part of our communications architecture. 
NASA is developing the DTN protocol suite that extends the terrestrial Internet capabilities into highly stressed data 
communication environments where the conventional Internet protocols do not work well. The DTN protocol suite 
is being standardized by the Consultative Committee for Space Data Systems (CCSDS) and all of the DTN protocols 
will be international standards, supported by open-source software that can help users implement new capabilities. 

The development of the DTN protocol is not within the scope of the AAE project, but we are incorporating new 
DTN capabilities as they are developed. More importantly, we are performing trade studies to determine the best 
location to host DTN within the spacecraft architecture, including key considerations such as size, weight and 






power, processor utilization, storage capacity, device real estate, and required data rates. The AAE project is also 
studying the impact of having DTN nodes at other locations within the end-to-end communication architecture, 
considering factors such as network reliability, implementation costs, and the need for international interoperability. 


So far in FY14, we have been able to enhance the previously developed DTN-enabled SDR and a baseband 
processor by adding Bundle Security Protocol (BSP) capability (Ref. Figure [III.B.2] and [III.B.3]). This capability 
was successfully demonstrated during Integrated Test #4. We have also added Bundle Authentication Blocks 
(BAB), Payload Integrity Blocks (PIB) and Payload Confidentiality Blocks (PCB); These will be evaluated as part 
of the DTN Management Protocol testing during IT#6. 
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Figure III.B.2. Disruption Tolerant Networking (DTN) Stack - BSP is new for FY14. 
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Figure III.B.3. Enhanced Baseband Processor / Software Defined Radio 

We also initiated an effort at GRC to make both the RIACS (Reconfigurable, Intelligently-Adaptive 
Communication System) and Universal Software Radio Peripheral (USRP) SDR platforms compliant with NASA 
Space Telecommunications Radio System (STRS). STRS is an open architecture for NASA space and ground radios 
that provides a common, consistent framework to abstract the application software from the radio platform hardware 





and reduce the cost and risk of using complex configurable and reprogrammable radio systems across NASA 
missions. For the remainder of FY14, we will continue with the development of the RIACS SDR platform on a “best 
effort” basis, and we have established a stretch goal to demonstrate a STRS compliant platform during IT#6. 

One of our primary communication goals for FY14 was to demonstrate communication between Marshall Space 
Flight Center’s PULSAR SDR and other existing AAE SDRs. Unfortunately, there have been significant delays in 
MSFC’s delivery schedule. We still hope to receive it before the end of FY14, but integration of it with existing 
SDR platforms during Integrated Test #6 seems unlikely. 


As part of our communications architecture shown in figure [III.B.l], we are committed to establishing an in- 
space wireless mesh network. Wireless mesh networks are decentralized and do not rely on existing infrastructure, 
but can route through other nodes. Mesh networks enable rapid deployment, provide coverage in undeveloped 
regions and are self-healing, resilient, and extensible. Mesh networks can offer lower size, weight, and power 
(SWaP) than overlapped infrastructure -per-application. Standardized mesh networks are heterogeneous, allowing for 
multiple vendor implementations or sources. Several potential Mesh Networking applications for Human 
Spaceflight are show in figure [III.B.4]. 



Figure III.B.4. Potential Mesh Networking Applications for Human Space Flight 


During FY14 we have demonstrated standardized wireless mesh networking using the 802.11 Hybrid Wireless 
Mesh Protocol (HWMP). We have also demonstrated DTN voice and text messaging applications running over the 
802.11 mesh network, using the IBR DTN implementation running on Android phones that are clients of the mesh 
network. We have also demonstrated the Bundle Streaming Service Protocol (BSSP) operating over the mesh 
network. BSSP is similar in concept to the original BSS, but is redesigned as a convergence-layer protocol under BP 
with its own retransmission signaling, to enable multicast transmissions. 

We will continue to add to our Mesh Network infrastructure during the remainder of FY14 on a “best effort” 
basis. In the future, we plan to address items such as Mesh Security Mechanisms, gateway congestion. Cognitive 
Algorithms, and other technologies such as 802.1 lac, 802.1 lad, 4G LTE Advanced, and CCSDS Proximity-1. 


C. Wireless Systems 

Our goal for the wireless systems element is to extend standards-based wireless technologies to space 
applications including sensing, control, and telerobotics. In order to accomplish this, we are prototyping relevant 
technologies and we are ensuring that our results support international space wireless standards development 
activities. For example, we are evaluating 802.11 network technologies using 802.1 ln-enabled wireless sensor 
network (WSN) nodes for high-bandwidth sensing applications EVA applications. 

So far in FY14, we have implemented and evaluated a baseline wireless sensor network (WSN) architecture by 
developing a CFS interface for a Nivis ISAlOO.lla WSN gateway and deploying a multi-hop, mesh personal area 
network (PAN) using the CCSDS-recommended ISAlOO.lla standard. In addition, we tested and demonstrated the 


ISAlOO.lla network by monitoring temperature in the ECLSS lab of building 7 at JSC and thruster pressure from 
the iPAS facility. 

We have also implemented various improvements to the Wi-Fi-operated free flyer analog developed in FY13 
(shown in figure [III.C.l]). These include upgraded MJPG video streaming software, an extended robot control 
remote interface using UDP (w/emergency stop), and an improved RFID interrogator control remote interface. 
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Figure III.C.l. AAE Tele-Operated Free-Flyer Analog 


Using the improved free flyer analog, we were able to demonstrate RFID-enabled temperature sensing with 
store-and-forward overlays, and node/interrogator custody transfer which enables sensing when the interrogator is 
absent. With this arrangement we achieved 100% data recovery using an external thermocouple (shown in figure 
[III.C.2]) and roving interrogator (shown in figure [III.C.l]). 



Figure III.C.2. Prototype RFID Temperature Sensor 




We were also able to demonstrate capture/display of pressure transients (waveform capture) during cold-gas 
thruster firing utilizing the aforementioned Wi-Fi sensor node, built from modular components, as shown in figure 

rm.c.3]. 




Figure III.C.3. Thruster Pressure Transducer waveforms captured with a Wi-Fi sensor node. 


During the remainder of FY14 we plan to emphasize our work with RFID sensing. We will build and integrate a 
modular interface for the existing RFID smart memory chipset, and investigate other RFID smart memory chipsets 
at dev-kit fidelity. In addition, we will build and integrate developmental flight instrumentation (DFI) sensor 
package (temperature/ strain) to study RFID sensing utility. 

For all of our wireless networks (ISA100.1 la and Wi-Fi) we will continue to collect test results/metrics (as 
resources permit) on packet latency, packet loss rates, throughput rates, energy consumption, interference tolerance, 
and node failure tolerance. As resources permit, we will also integrate more low and high-data rate pressure 
transducer nodes in order to run additional tests and explore the limits of our approach. 


D. Human Interfaces 

The goals of AAE Human Interface (HI) work are to identify, adapt, develop and mature innovative, integrated 
spaceflight human interface technologies that will meet the needs of NASA’s planned deep space crewed missions; 
and to infuse Human Systems Integration (HSI) from beginning to end of the project lifecycle, optimizing the 
system for crew time, personnel, training, human factors engineering, safety, health, survivability, and cost. 

Ultimately, we intend to collect information about command & telemetry data rates; display view change events; 
number of displays with live data; data display rates; and cockpit configuration suitability using various display 
technologies and formats and various control techniques. Figure [III.D.l] shows the test Human Interface test 
configuration used for IT#5. 

We have provided a number of system-level displays for use in the MPCV Cockpit mock-up, and we are now 
exploring alternative display development system techniques for rapid prototyping and testing. We are also adding a 
Rotational Hand Controller and evaluating the use of Foot Pedals as a control device. 

We have also made use of a NASA@Work challenge to help us develop new display tools for DSH/EAM/F.F 
Hab evaluations / comparisons. Submissions were evaluated and award given to dcApp (displays & controls app) 
developer. We have built a single display using this tool and will evaluate its commanding capabilities during IT#6. 
Depending on available resources, we will also develop and test EAM AMPS (power) and CDS (water) using 
dcApp. 

We have successfully demonstrated our ability to render displays by implementing our sGPU on an AiTech 
C903, and we are in the process of porting in to an AiTech C925. 
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Figure III.D.l. Human Interface test configuration for AAE IT#5 


In partnership with Honeywell, to evaluate on-orbit usability of OLEDs displays, we completed EMI, Thermal 
VAC, and Radiation testing, and provided the results in a publically available report 2 . We continue to negotiate with 
Honeywell for follow-on evaluations of newer OLEDs displays under the auspices of a Non-Reimbursable Space 
Act Agreement. 

In addition to cockpit-type displays, we are continuing our efforts to develop a more immersive environment 
(with both imagery and audio) in an enclosed dome. One of our university partners, Kanas State University, has 
delivered an adjustable flooring structure for our dome and now we will proceed with a follow-up project to upgrade 
our flight deck mockup. We have been able to demonstrate visuals in the dome by using a Newtonian Mirror system. 
Unfortunately, results were disappointing: warping correction did not work as expected, and the required position of 
system was problematic (too sensitive to vibration, etc.). We are now looking at the use of real-time software 
morphing of images already provided using our simulation graphics. 

In preparation for future exploration missions, we have begun to look at potential Telepresence capabilities - 
with a near-term focus on visual and auditory, and a longer term focus on tactile communication and sensory 
immersion. We are investigating the impacts of communication latencies and bandwidth variations on the perceived 
utility of Telepresence. We have already conducted a “3 Party Conference” effectiveness evaluation, with 
communications delays inserted for 1 of the participants. Unfortunately, resource limitations combined with other, 
higher-priority focus areas, will force us to limit activities in this area for the foreseeable future. 































E. 


Model Based System Engineering 


NASA has initiated efforts to implement Model Based System Engineering (MBSE). In an effort to gain 
experience in this area, the AAE Project adopted MBSE for our reference implementations. In the near-term, MBSE 
tools provide us with the flexibility to analyze and document a variety of architectures and share this information 
with other AES projects. Ultimately, this will support AAE goal of developing a reference implementation of the 
avionics architecture(s) that can be provided to industry (users) as a basis for standards and procurements. 

In FY14, we continue our MBSE efforts to “Evaluate by Implementing”. Our goals this year are to develop 
requirements and use case (ConOps) diagrams of our architecture including adding the ability to conduct dynamic 
analysis of attributes. We will also strive to include mass and power estimate. We also plan to evaluate our 
interfaces to existing simulation and testing software tools around the agency and in the academic and commercial 
sectors. 


For IT#5, the scenario under evaluation was focused on a docking event between the Exploration Augmentation 
Module (EAM) and the MPCV-Orion as shown in figure [III.E.l]. From a system of systems perspective, we are 
demonstrating in this scenario four systems working together to accomplish the docking phase of a mission: EAM, 
MPCV-Orion, DSN, and Ground Systems. 
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Prior to IT#5 we were able to complete a SysML representation for the AAE Rev 3.0 Architecture, using it to 
promote a clear understanding between stakeholders of the configuration being evaluated. Interface Block Diagrams 
of this model are shown in Figures III.E.2 & III.E.3. The system boundaries established in these diagrams specify 
expected subsystem to subsystem interfaces, signal formats, and protocols. 



Figure III.E.2. SysML representation (ibd) of MPCV for AAE Rev 3.0 Architecture 



Figure III.E.3. SysML representation (ibd) of EAM for AAE Rev 3.0 Architecture 






Characteristics of each component in the architecture are defined in a component library. Modifications to any 
part of the model are automatically updated in all views of the system (e.g. component attributes, system interfaces, 
component exchanges etc.). 


The approach used for IT#5 demonstrates the use of a central model to support the development of reference 
system architectures, and will be used for all future Integrated Tests. As part of our work for IT#6, we will complete 
AAE system model 4.0, and integrate it with the IPAS nest model to support reconfiguration and test setup. We will 
also develop a specific use case and corresponding activity diagram(s) to document and evaluate system behavior. 


IV. Future Strategy and Goals 

In FY15, the AAE Project will be combined with the Core Flight Software (CFS) Project, the Disruption 
Tolerant Networking (DTN) Project, and FDIR/Planning aspects of the Autonomous Mission Operations (AMO) 
Project. This new AES project will be known as the AES Avionics & Software Project. The purpose of the Avionics 
& Software project is to build a suite of tested and reusable avionics and software components that reduce cost and 
risk for future exploration programs and enable infusion of new technologies and capabilities into current Programs. 
This project will utilize Model-Based Systems Engineering tools to catalog the suite of avionics and software 
components, enabling trade-study analyses and overall system design to be easily performed based on mission 
requirements. 

The top level goals for this project are to: 1) develop avionics and software architectures that supports NASA 
goals for Beyond-LEO exploration “space vehicles” that may be modular, multi-vendor, and multi-IP 
configurations, and 2) evaluate design concepts in a system environment to verify ability to integrate diverse 
interfaces and evaluate system performance. We will be working towards an “open” architecture that allows use of 
hardware from multiple vendors, enables use of evolving (near launch) technology, and provides the ability to 
upgrade capabilities and infuse new technologies in a cost effective manner. 

We will be attempting to continue progress towards the goals of the constituent projects. This includes our intent 
to improve functionality, reliability, fault tolerance, and autonomy - while reducing size, weight, and power (SWAP) 
of Avionics. We will also continue to leverage terrestrial commercial capabilities to drive down development and 
sustaining costs of avionics and software. We will stay in sync with Agency road-mapping efforts, while focusing 
our efforts on the transition steps (e.g., TRL-6 to 7) to make things ready for Human Space Flight (HSF). 

This should enable HSF to benefit from technologies such as next-generation Rad Hard Avionics (Multicore, SOC) 
in a timely manner. 

Although specific plans and objectives are still in-work, we intend to evaluate additional architectures providing 
redundancy with dissimilar hardware, fault management and advanced caution & warning. We will also be 
simulating more dynamic situations such as entry, descent, and landing. We will be supporting other AES projects 
such as Advanced ECLSS and EAM. And we expect that some of our technology demonstrations will prove useful 
to both ISS and Orion. 


V. Conclusions 

During FY13, the AAE Project was able to successfully demonstrate a plausible avionics architecture for a 
notional L2 Station. We were also able to make significant strides toward our goal of a flexible avionics architecture 
that can be used to evaluate future concepts/architectures/components for both our nominal L2 Station and other 
vehicles. Our Rev 2.0 architecture provided a common core system that has standard capabilities and interfaces, and 
contains basic core elements and functionality needed for any spacecraft. If desired, this system could be scaled and 
tailored to any specified mission. The system incorporates hardware from multiple vendors, and reusable and 
reconfigurable open source software (e.g., GSFC CFS). 



Our FY14 efforts have been centered on incremental architectural upgrades applied to different mission 
scenarios. We have developed a Rev. 3.0 architecture and evaluated it during an Integrated Test in May 2014. We 
will develop a Rev. 4.0 architecture for evaluation during IT#6 in September 2014. 

In FY15, we are planning to merge the AAE project with the CFS project, the DTN project, and some aspects of 
the Autonomous Mission Operations (AMO) project, all funded from AES. The vision for this consolidated 
Avionics & Software Project includes the development of architectures and system designs which can be used for 
flight programs/programs in both the near and long term. 

For the near term, this means that we must provide a point solution targeted for an identified mission in 2-3 
years. Essentially this solution must be a “good enough” answer from the options we have, which can be matured for 
flight with minimal effort and used as a basis for procurement specifications. 

For the long term, our intent is to build a “catalog” of multiple solutions which can be used “mostly off-the- 
shelf’ for a variety of situations. This catalog will include specific components and overall architectures. 
Recognizing that one size doesn’t fit all, each will be rated for suitability to different mission types. New 
technologies will be incorporated in a timely manner in order to take advantage of strides being made by industry to 
drive program development and sustaining costs down. This strategy should allow us to include vehicle “hooks & 
scars” for later augmentation; facilitate component repair, replacement, and upgrades; and take advantage of 
schedule slips during the development phase with improved hardware. 

We remain committed to demonstrating the technical and economic benefits of our approach, but the amount of 
progress we are able to make is dependent on funding and resource constraints, along with the priorities set by the 
Agency for Human Spaceflight. 

Our team already includes participants from most NASA centers and industry, but we recognize the need to 
widen participation from NASA and other government agencies, add more industry and academic partners, and 
begin discussions with potential international partners during the coming years. We look forward to engaging these 
future stakeholders. 
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